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® A directory dabatase system includes a network 
and 8 plurality of directory service units (DSU), each 
of the DSUs providing one or more directory service 
functions within the directory database. For propaga- 
tion of an undirected user query relative to an object 
5! in ^« database from a source DSU to one or more 
^target DSUs. one of which may contain information 
relative to the object, a propagation (P) table is 
provided in each of the DSUs. the P tables being a 
*^data structure capable of detenmining which other 
CO DSUs to send the user query to. 

The source DSU examines its associated P table 
for the directory type specified in the query to gen- 
Oerate an identification of one or more additional 
(^target ones of the DSUs to which the query should 
UJt>e directed. After propagating a query from the 
source DSU to those additional DSUs identified by 
the P table in the source DSU, there is returned to 



the source DSU information responsive to the user 
query from the one of the additional target DSUs 
containing the information. 
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PROPAGATION APPARATUS FOR NETWORK QUERIES THROUGH SUPERIOR-SUBORDINATE AND PEER- 
PEER DATA DISTRIBUTION RELATIONSHIPS 



CROSS-REFERENCE TO RELATED APPUCA- 
T10NS 

The following copending applications, all filed 
by the same assignee as the present application, 
are related to the subject matter of this applrcation, 
in that , they each relate , to different aspects of a 
directory database system. 

(Al) "Generalized Data Directory Model", 
Application N' 

(A2) "Generalized Algorithmic Control Blocks 
for Sequential and Parallel Queries in Distributed 
Directory Networks", Application N* 

(A3) "Dynamic Update of Database Direc- 
tories Using Directed or Undirected Mechanisms", 
Application N* 

(A4) "Hybrid Directory Data Distribution 
Schemes for Network Topologies", Application N* 

All of these applications {filed concurrently with 
the present applicatton) are incorporated herein by 
reference. 

BACKGROUND OF THE INVENTION 

Field of the invention 

This invention relates to systems for propaga- 
tion user queries through a database network; the 
system being independent of the network topology. 
In 'the present application the term "directory" 
means a table of names and corresponding items 
of data. Data in a directory is locatior^l or directive 
in nature, e.g. 

(1) a listing of names, addresses, and other 
data about a specific group of persons or organisa- 
tions, or 

(2) an index that is used by a control pro- 
grarh to locate one or more blocks of data stored in 
separate areas of a data set in direct access stor- 
age, or 

(3) an index to locate blocks of program ir>- 
fcrmation. The user of a directory knows the defini- 
tion of the object references by a name, but needs 
the specific data value(s). e.g. phone number, in 
order to perform a specific activity. 



Description of the Prior Art 

Distributed database management systems of- 
fer users the ability to distribute data and workload 

5 amor^ multiple processing sites. Ideally, a distrib- 
uted database management system should support 
growth while preserving local administrative auton- 
omy and control of access to locally stored data. At 
the same time, the distributed database should 

70 provide its users with a single system image such 
that, although tfie data is distributed among several 
sites, the data distribution is transparent to the 
users who expM-ess their database accesses as 
though the data is at one place. 

15 H is important to preserve the locaJ autonomy 

of database administrators and users at each site 
of the distributed database while, at the same time, 
supporting information sharing among sites. It is to 
expected that the equipment supporting the 

20 database at different sites will controlled by 
different administrative entities. This expectation in- 
creases as the entry costs for computing faciQties 
decline. Increased distribution of computing facili- 
ties leads to additional requirements for information 

25 sharing between sites to support the shared objec- 
tives and interests of the users at different sites. 
Therefore, credible access control mechanisms 
must be provided to insure isolatksn, when desired, 
and to control access to the shared information. At 

30 the same time, users must be at}fe to easily access 
and manipulate remote data as though it were 
local. 

The distributed database management system 
architecture should preserve local control and func- 

ds tion when accessing local database objects. The 
fact that a site participates in the distributed 
database should not reduce that site's ability to 
perform local actions on local data by requiring the 
partk:ipation of other sites. Also, data access avalh 

^40 ability should be a function only of the availability 
of the site(s) storing that data objects. The failure 
of one site should not impact sites which do not 
reference datat>ase obiects stored <or controlled) 
by the failed site. 

45 Finally, it must not be difficult for an existing 

database site to join the distributed datat>ase. It 
should be fairiy easy for an existing datat>dse site 
to establish the ability to access data at another 
site- The addition of another site to the distributed 

50 database must noX require a nationwide (or global) 
system generation. 
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U.S. Patent 4,468.728 discloses data structure 
and a search method for a database management 
system in which the data structure is airranged in a 
plurality of search trees. The initial search tree and 
an initial subset of trees are maintained in a main 
fast access memory, while the remaining trees are 
kept in mass memory. An input search parameter 
is partitioned into a plurality of subparameters, one 
for each search tree. The subparameters are used 
to search a tree in each level of the data structure 
until the location of a terminating file is determined. 

An article entitled "Object Naming and Catalog 
Management For a Distributed Database Manager". 
Lindsay. 1981 IEEE, page 31. describes a system 
in which distribution of the catalog representation 
and maintenance leads to an architecture which 
supports transparerrt user access to data which 
may be distributed, replicated,* and partitioned 
among the site of the distributed system. The ar- 
chitecture preserves individual site autonomy while 
facilitating graceful system growth. 



SUMMARY OF THE INVENTION 

The - requirements placed upon the query 
mechanism provide the rationale for the mecha- 
nisms thenr\selves. The requirements are as fol- 
lows: 

1. Full Accessibility: This Is the basic re- 
quirement. It states that If a piece of information is 
stored in the directory services system, a user at 
any DSU in the system should be able to gain 
access to that information. This should be possible 
even if the user does not know precisely where that 
information is stored, or the way in which data is 
'distributed through DSS. The requirement is sub- 
ject to several exceptions such as security or ac- 
cess control restrlcttons. However, in general, the 
design of the query mechanisms is be primarily 
driven by this requiren^nt 

2.Subset-Ability; This requirement states that 
ail DSUs participating in a DSS need not imple- 
ment the full function of the query mechanism in 
order for the first requirement to be satisfied. For 
example, small work stations in a DSS may not 
wish to act as an intermediate node in query prop* 
agation. but the users of the DSS may still require 
full accessibility. Implied in this requirement is the 
necessity for compatibility between different sub- 
sets operating within the same DSS- 

3. Performance: Performance can be mea- 
sured in many different ways. The major perfor- 
mance criteria are: 

a. Bandwidth: It Is cleariy desirable to 
minimi2e the number of messages sent through the 
networic by the query mechanisms, thereby freeing 
network bandwidth for other purposes. 



b. Storage: Minimizing storage is particu- 
larty important in environments which consist of 
small minicomputers and/or work stations. 

■c. Delay: This refers in particular to query 
5 response times. 

The algorithms employed in the present inven- 
tion are designed, as far as possible, to minimize 
the above criteria. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

Rg.l is a block diagram illustrating pro- 
cesses using a directory service system; 
75 Fig. 2 is a block diagram illustrating intercon- 

nected DSUs in a DSS; 

Rg. 3 illustrates the processing functions 
distributed in a DSS; 

Fig. 4 illustrates a two-level hybrid directory 
20 system; 

Fig. 5 shows the structure of the end user 
service P(U); 

Rg. 6 is a block diagram illustrating the 
structure of the directory function service P{F); 
25 Rg. 7 is a block diagram showing the struc- 

ture of the directory data service P(D); 

Fig. 8 illustrates the structure of the network 
service process P(N); 

Rg. 9 shows the distribution of directory 
30 service processes In a DSS; 

Rg. 10 illustrates DSl request flows among 

DSPs: 

Rg. 11 illustrates the reply flows among 

DSPs; 

35 Rg. 12 is a block diagram of the overall 

structure of the system of the present invention; 

Rgs. 13 and 14 illustrate the processing 
sequences for update and query propagation, re- 
spectively, in accordance vwth the present Inven- 

40 tion; 

Rg. 15 is a representation of a typical direc- 
tory operation control block; 

Rg. 16 shows the flow of a directed query in 
accordance with the present invention; 
45 Rg. 17 illustrates the flow where a special 

directory is queried to obtain a target DSU iden- 
tification for a directed query; 

Rg. 18 shows the propagation of an un- 
directed query; 
50 Rg. 19 Illustrates an example of undesired 

looping between two DSUs during a query; 

Rg. 20 shows a representative query P-table 
. (OP) and au update P-tabie (UP); 

Rg. 21 is a pictorial representation of a 
55 Superior-Subordinate <SUP-SUB) .relationship be- 
tween DSUs; 

Rg. 22 illustrates the flow for P-table transla- 
tion for the SUP-SUB relationship shown in Rg. 21; 
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Fig. 23 is a representation of DSUs having a 
Peer-Peer relationship to each other: 

Fig. 24 shows the P-table translation for the 
DSUs of Rg. 23; 

Fig. 25 is a representation of DSUs having a 
Beplicated relationship to each other; 

Fig. 26 shows the P-table translation for the 
DSUs of Rg. 25; 

Figs. 27-30 illustrate a number of other rela- 
tionships among other DSUs; 

Rg. 31 shows a UP-table illustrating parallel 
propagation to a number of SUP DSUs; 

Rg. 32 shows a QP-table for the parallel 
propagation to SUP and PEER DSUs; 

Fig. 33 shows a QP-table tor the parallel 
propagation between SUP and PEER DSUs: 

Rg. 34 illustrates a typical query message 
propagated in accordance with the present inven* 
tion: and 

Rg. 35 shows a typical response to a query. 



DESCRIPTION OF THE PREFERRED EMBODI- 
MENT 

In the descriptian and drawings, the followtr^ 
terms are used with the indicated meanings. 

AoolicatTon Interface (API) -The protocol 
boundary between the user and the directory ser- 
vice. 

Directory Service Interface fDSH -The internal 
interface between directory service units and out- 
side services, such as communication, user ser- 
vices, or user data areas. 

Directory Service System (DSS) -An Instance 
of directory service in a given network of distrib- 
uted directory services. 

Directory Service Unit (DSUV Au unit of DSS 
that provides one or more cErectory service func- 
tions. 

Prior to a detailed description of the present 
invention, the following overview of the environn>ent 
and elements of the invention are given. 

The basic structure of the directory database 
system of the present invention in -shown in Rg. 
12. Rg. 12 illustrates the different interfaces or 
protocol bourKiaries between the DSU shown in the 
dotted enclosure and other portions ot the system. 
Theses tKJundaries include a user protocol bound- 
ary shown at the top of the figure, a data access 
protocol t>oundary at the right side of the figure 
representing the interface between the DSU and 
the database, and a communications protocol 
boundary Illustrated at the bottom of the figure. 



The present structure and method is based on 
a distribution scheme where an instance of direc- 
tory service may include on or more DSUs. Each 
DSU may perform one or more directory functions 

5 depending upon the product implementation. 

The directory service system (DSS) shown in 
Rgure 1 is an Installation of directory functions in a 
network of interconnected system. DSS provides 
the architectural directory services for tfie user at 

10 the API protocol boundary. The partidpating sys- 
tems (products) in a DSS operate coherently under 
the architected rules such as data distribution - 
schemes, naming schemes, search/update algo* 
rtthms. error recovery, synchronization and the like. 

T5 A DSS is comprised of a collection of directory 

service units distributed troughout the intercon- 
nected system network as shown in Rgure 2. A 
DSU represents the directory service component of 
a system product implementing directory service 

20 functions. Although multiple DSUs may exist in the 
same system (product) for different applications, it 
is the intent that a single DSU can support many 
ap>plications programs to eliminate duplk:ation. 

25 

DSU. Functions 

A DSU is composed of a set of functional 
components called directory service processes - 
30 (DSP) to provide the sut>setfing basis for imple- 
mentation by products. There are the following four 
types of DSPs, each of which performs distinct 
functions. 

1 . User Service Process, denoted as P(U) or 
55 U, manages the interface (protocol boundary) with 

users. 

2. Directory Furwtion Process, denoted as P- 
(F) or F, processes the directory functions to ser* 
vice the directory request using the algorithms 

^ (queryAjpdate/naming). 

3. Directory Data Service, denoted as P(D) 
or D. martages the access and maintenance of the 
directory data. 

4. Network. Service Process, denoted as P- 
45 (N) or N. manages the transport network facilities to 

communicate wWi other DSUs. 

In order to obtain full directory service, it is not 
necessary that every DSU in tiie system implement 
all DSPs. For example, a work-station may imple- 

50 ment only some of the functions and obtain full 
directory service through interaction with a larger 
system product. Thus, a DSU may contain all four 
DSPs or some of the DSPs as necessary to meet 
the functional needs of each product 

55 Rgure 3 shows an example of implementation 

options by products in a simple network. DSU A 
and DSU D represent the work-station which per- 
fomns the query on an as needed basis and dis- 
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cards the results ot the query without retaining it in 
the storage. This type of product may not have to 
impiement P(D). DSU C represents another type of 
work-station which retains the results of a query in 
its local directory. This type of product needs to 5 
implement P(D). DSU B represents the file server 
which acts merely as a data repository to maintain 
the master directory for the network. This type of 
product may not have to implement P(U). 

10 

DSU Roles 

In order to perform a directory service in a 
distributed network environment, several DSUs are i5 
generally involved and each DSU plays different 
roles. The origin or source DSU receives a direc- 
tory request from the user and originates the DSl 
request. The request is propagated through the 
intermediate DSUs as necessary to reach the tar- so 
get DSU which can service the request. 



Directory Data Base 

I 25 

A directory is a database that stores mappings 
from name to information related to name. The 
directory data base is a set of directories wWch 
contain information of a similar type. There is more 
than one memt>er in the set if the directory data - 30 
base Is distributed across participating DSUs. The 
directory data base and all members which com- 
prise It are named via a directory type ID (Directory 
Identifier). For example, a directory database with 
directory type_ID TELEPHONE may contain name 36 
to telephone number mappings. A single DSU may 
•maintain directories of different directory 
type_ID*s, but for any given type_!D, a DSU may 
contain at most one directory. 

40 

Directory Distribution 

Some examples of directory distribution - 
schemes are as follows: 

Centralized Directory System 



In this centralize directory system, there is a 
single master directory per directory type-ID lo- 
cated at one of the DSUs. The master directory will 
be updated whenever a change takes place. Direc- 
tory updating in such a system is relatively easy. 
However, there are communication costs (traffic) 



incurred for each query, information at each DSU, 
as well as the communication cost for updating all 
these directories. 

Hybrid Directory System 

For networks up to a few tens of DSUs. a 
single level (primitive) distribution scheme de- 
scribed above (that is. centralized, localized and 
distributed), is usually sufficient. Beyond this num- 
tjer of nodes, hybrid systems combining various 
primitive distribution schemes In a hierarchical 
manner, as illustrated in Rgure 4, may be attrac- 
tive. The hybrid multiple level design can offer both 
types of performance improvements over a single 
level design. 

The hybrid directory system is logically divided 
in subsystems, or regions, made up of any number 
of distributed directory services. Each subsystem 
uses different (primitive) directory distribution - 
schemes to fit into its regional environment The 
hierarchical relationships between subsystems are 
Independent of the actual topology of the physical 
network. 



DSU-DSU Relationship 

A directory service can define the functional 
relationship among the DSUs distributed in the 
network due to the following aspects: 

The relationship provides a method of organizing 
the DSUs distributed in the network to allow the 
definition of simple and efficient protocols for the 
propagation of DSl commands such as 
query/update. In particular, the relationship can be 
used to constrain the set of DSUs to which a 
particular DSU can send a DSl command for 
query/update. The relationship is used to control 
how to distribute the directories, per directory type, 
among DSUs and how to maintain the respective 
directory, in some of the directory applications, the 
relationship of a particular set of DSUs might re- 
flect the organisation structure of the entreprise 
owning the network, even though the network topol- 
ogy does not. 



DSU-DSU Communication 

The lines joining the DSUs in Figure 2 indicate 
the communication paths. Communication between 
55 DSUs may be accomplished through the use of 
any one of several .different transport mechanisms. 
For example, DSUs may communicate with each 
other by running as a set of transaction models 
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using IBM's. System Network Architecture (SNA) or 
equivalent level of transport facilities. In this case, 
the lines represent sessions and may not resemble 
in any way the physical topology of the network. 
The only assumption that the directroy service 
structure makes about the nature of the transport 
mechanism is that it provides guaranteed error-free 
delivery of data from source to destination. 



User DSU Interface 

The user makes a directory function request by 
way of the API verbs to one of the DSUs. The 
-requested DSU interacts with other remote DSUs, 
and then provides the appropriate response to the 
user. 



DIRECTORY SERVICE PROCESS (DSP) 

This section describes the functions and struc- 
ture of each DSP. In practice, the DSPs may be 
implemented either in programming or by a micro- 
processor. 

End User Service Process P(U) 

The P(U) basically manages the protocol 
boundary to service the end user request Only P- 
(U) irrterfaces with the API. thus shielding other 
DSPs from the end user. At the request of the end 
user. P{U) parses the received vert>s and sends the 
directory request to P<F) for the 
Information/response ponse. When it receives the 
infomr^tion/response from P<F), it returns it to user 
to satisfy the original API verb. 



Structure of P(U) 

As shown in Rg. 5, P(U) consists of a set of 
API vert? processors, each of which has two com- 
ponents (API send processor and API receive pro- 
cessor). The API send processor is to parse the 
API verbs and its associated parameters from the 
user and construct the DSI request encoding to be 
sent to P(F=) for specific directory tasks as re- 
quested in the API verbs. The API receive proces- 
sor is to decode the received DSI replies and 
present the inform ation/data (canried in the reply) to 
the user protocol boundary according to the de- 
fined API rules. 



Directory Function Service: P(F=) 

The P(F) performs the essence of distributed 
directory functions such as search/update algo- 
5 . rithms and naming algorithm. P(F) is knowledge- 
able of the existence of distributed directories and 
name database (if any), and it provides a focal 
poirtt for maintaining currency among them in the 
system. 

70 The P(F) is responsible tor providing the in- 

formation response satisfyirtg the request from P- 
(U). P(F) maintains/ manages the directory opera- 
tion control block to be used by the directory 
algorithm facilities. The control block contains the 

15 algorithm control information such as affinity lists. 
P(F) uses this information to determine the best 
way to get infonmation and respond to the requests 
from P<U). P(F) interacts with other remote P(F)s as 
necessary to locate the target P(F) (that is. the P- 

20 (F) directly linked to the P(D) which can access 
requested directory data). The target P(F) obtains 
the directory data from the D <P). and sends it to 
the source P(F) (that is, the P(F) that originally 
received a request from P(U)>. Then the source P- 

25 (F) passes the directory data to the P(U) that 
originated the request P(F) is the brWge form of 
service interacting with both P(U) and P(D), as well 
as P(N). 

30 

Structure of P(F) 

As shown in Rg 6. P(F) consists of a set of DSI 
command processors, each of which has two com- 
as ponents (DSI request processor and DSI reply pro- 
cessor) to process the received requests and re- 
plies respectively. The format of the input to the P- 
(F) shouk* preserve the DSI command construct 
regardless of whether the command is received 
40 from the P(U) or the remote P(F)s through the 
communication network. 

The DSI request processor the OSl processes 
the DSI requests received from either P(U) or re- 
mote DSUs. It uses the directory algorithm facilities 
45 such as the query/update propagation alogorithm 
and the name assignment algorithm as appropriate. 
The directory algorithms determine the target DSU 
which can provide the requested information. If the 
receiving DSU is determined to be the target DSU. 
so the DSI request processor fetches the requested 
inforrhation by way of P(D) and sends the DSI 
reply carrying that information to the origin DSU. 
Otherwise, the DSI request processor passes the 
received request to the other DSU as the algorithm 
55 determines, based on the affinity lists of the opera- 
tion control block. 
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The DSI reply processor processes the DSl 
replies which carry the information requested by 
the DSI requests. If the receiving DSU is the origin 
DSU (which originated the DSI request), the DSI 
reply processor passes it to the local P{U). Other- 
wise, it sends the received DSI reply toward Vne 
origin DSU. 



Directory Data Service: P(D) 

The P(D) manages the directory data access 
protocol boundary to access and maintain the di- 
rectory data. Only P(D) has knowledge of the struc- 
ture of the directory contents by way of the direc- 
tory descriptors specified by the users, thus shield- 
ing other DSP's from the directory data structures. 

The P(D) receives the directory data request * 
(query, update and so on) from P(F), performs the 
appropriate operation on the directory data by way 
of the data access protocol boundary and responds 
as appropriate to the P(F). it is the responsibility of 
P(F) to locate the target P(D) (that is. the P(D) 
maintaining the requested directory data) before 
sending a request to that P(D). 



Structure of P(D) 

As shown in Fig. 7. the P(D) consists of two 
processors. Read and Write. The read processor 
services the DSI requests (for example, query), 
from P(F). which requires reading the directory 
data through the data access protocol boundary. It 
reads the requested directory data according to the 
directory descriptors znd returns the retrieved data 
*by way of the appropriate DSI reply to P(F). The 
write processor services the DSI requests (for ex- 
ample, update), from P(F). which requires writing 
tiie directory data through the data access protocol 
boundary. It performs the directory d^ta update as 
requested, according to the directory descriptors, 
and returns the results, if necessary, via the appro- 
priate DSI reply. 



Directory Networi< Service: P(N) 

The P(N) provides the ability to send and re- 
ceive the DSI commands between DSUs. It inter- 
faces with the transport mechanism used for DSU- 
DSU communication, thus shielding other DSP's 
from the networking furKlion. P(N) controls the 
networl< protocol boundaries to achieve the P(F) to 
P(F) conversation between remote DSUs. The con- 
tent of DSI request/replies are basically transparent 
to P(N). and the function of P(N) is merely to 
deliver the DSI requests/replies to the remote P(F)- 
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•s through the network. Also, the P(N) does not 
determine where to send queries or updates. This 
is determined by the propagation algorithm in the 
P(F). 



Structure of P(N) 

As illustrated in Fig. 8, the P(N) consists of two 
processors, send and recede. The ser>d processor 
is to control the sending of data in a DSU-DSU 
communication. The receh^e processor Is to receh^e 
data from the DSU-DSU communication. The func- 
tions of these processors have direct dependencies 
on the protocol boundary of the network used for 
DSU-DSU communication. The directory strucUire 
descrik)es the specific functions of P(N) required to 
use the DSU-DSU transport mechanisms. 



Structure of P(F) 

As shown in Fig. 6. P(F) consists of a set of 
DSI command processors, each of which has two 
components (DSI) request processor and DSI reply 
processor) to process the received requests and 
replies resF)ectively. The format of the input to the 
P(F) should preserve the DSI commarwJ construct 
regardless of whether the commarKi is received 
from the P<U) or the remote P{F)s through the 
communication network. 

The DSI request processor processes the DSI 
requests received from either P(U) or remote 
DSUs. It uses the directory algorithm and the name 
assignment algorithm as appropriate. The directory 
algorithms determine the target DSU whic^i can 
provide the requested information. If the receiving 
DSU is determined to be the target DSU, the DSI 
request processor fetches the requested infonma- 
tion by way of P(D) and sends the DSI reply 
carrying that information to the origin DSU. Other- 
wise, the DSI request processor passes the re- 
ceived request to the other DSU as the algorithm 
determines, based on the affinity lists of the opera- 
tion control block. 

The DSI reply processor processes the DSI 
replies which carry the information requested by 
the DSI requests. If the receiving DSU is the origin 
DSU (which originated ttie DSI request), the DSI 
reply processor passes it to the local P(U). Other- 
wise, it sends the received DSI reply toward the 
origin DSU. 
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Directory Data Service: P(D) 

The P(D) manages the directory data access 
protocol boundary to access and maintain the di- 
rectory data. Only P(D) has knowledge of the struc- 
ture of the directory contents by way of the direc- 
tory descriptors specified by the users, thus shield- 
ing other DSP's from the directory data structures. 

The P(D) receives the directory data request - 
(query, update and so on) from P(F). performs the 
appropriate communtcation. The functions of these 
processors have direct dependencies on the pro- 
tocol boundary of the network used for DSU-DSU 
communication. The directory structure describes 
the specific functions of P(N) required to use the 
DSU-DSU transport mechanisms. 



Relationships Between DSPs 

A DSS can be viewed as a collection of an 
arbitrary number of P(U)s. P(F>s, P(D)s and P<N)s - 
(Rgure 9). A DSU must contain at least a P<F) and 
a P(N). although the levels of complexity of the 
functions to t)e performed vary depending on the 
roles of the DUS wthin a DSS. DSI commands are 
used as the message units to carry information 
from one DSP to another. There are two types of 
OSI commands. DSI request dans DSI reply. The 
DSI request is used to carry the speafic request 
information to the target DSP, and the DSI reply to 
carry the information/response to the origin DSP. 

Based on the definitions off DSPs discussed 
above, the foMowrng relationship can be construct- 
ed to depict the message flows among DSPs -P- 
(U). P(F), P(D) and P(N). 

• Figure 1 0 shows the DSI request flows among 
DSPs. The possible flows are: (1) P(U) -P(F). (2) P- 
(F) -P(F) by way of P(N)s, and (3) P{F) -P(D). 
figure 1 1 shows the DSI reply flows among DSPs. 
The possible flows are: (1) P(D) -P(F). (2) P(F} -P- 
(F), and (3) P(F) -.P(U). 



Usage of Protocol Boundaries 

Thus, the present system definies one protocol 
boundary for its users and uses three different 
protocol boundaries to formally describe the sys- 
tem structure. A DSU provides the protocol bound- 
ary for the user to send the directory requests to 
DSU and receive the directory 
information/response from DSU. DSU uses the pro- 
tocol boundary of a communication network to 
communicate with another DSU in another system. 
Another protocol boundary is used by DSU to 



control accesses to ar>d read and write the data in 
a directory data model. The functions of these 
verl^s may be implemented in a product unique 
manner. 

5 In connection with Figs. 13 and 14 illustrating 

the processing sequence for update and query 
propogation, respectively, there are separate pro- 
cessors shown for update reply, update request, 
query reply and query request. However, if a given 

70 DSU is not involved in query propagation, only the 
update processors are required. 

As shown in Fig. 15, the present invention 
employs a directory operation control block. The 
operation control block contains informations which 

75 controls the directory- system furictions performed 
on behalf of the user. This component includes 
search (query) atgortthm control rnformatlon, and 
internal tables which define the relationship of tNs 
member user directory with other memtjors (at 

20 other DSUs) within a particular directory database. 

The directory operation control block shown in 
Fig. 15 supports directory system services such as 
automatic search eind automatic maintenance to the 
user. This control bk>ck is associated with a par- 

25 ticular memt>er of the directory database, and the 
information containefl therein Is locatiorwiependent. 
This control block Is usually initialized by way of 
directory system generation parameters, although 
changes to internal operation of the directory sys- 

00 tern to this member may occiir dynamically 
through the protocol boundary. 

The directory operation control bk)ck contains 
the affinity list search algorithm control field. Integ- 
rity parameters field, and access control field. 

35 which can be described as foltows. 

Affinity List : The affinity list descrit>es the togi- 
cal relationship between this member and other 
members of a particular directory database. The 
affinity list data values describe whether other di- 

40 rectory database members are superiors, peers, or 
subordinates to this member. The manner in which 
directory data is distrilnjted, and logically config- 
ured, can therefore be derh^ed from affinity list data 
values. A consequence of affinity list design er>- 

45 ables a reconfiguration of user data (say, from a 
centralized to a distributed configuration) by subse- 
quent changes to affinity list data values. 



50 Search Algorithm Control 

This field supports various user options of the 
automatic name resolution function. Such options 
may include action to k>e taken by the DSU upon 
55 determining a "not found* condition at this mem- 
ber, such as report an 'error", continue searching 
using internal search algorithms, or return a data 
value to the user. 
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There may be cases where a cascaded search 
is possible using participating members* affinitiy 
tables-. Similarty, some members who do not sup- 
port this capability can terminate the search from 
continuing beyond this point: this may be useful to 
support products of varying capabilities in a depth- 
first search algorithm. 



Integrity Parameters 

Degrees of error tolerance^ or of consistency of 
user data within the distributed directory database, 
are supported by means of the integrity parameters 
field. These can be described by the user at im- 
plementation. 



The User-DSU Interface 

The protocol boundary verbs (API) used in the 
query functions may include the following which 
are described in rough functional form. The de- 
scription is meant only to provide sufficient detail to 
enable the understanding of the query mechanisms 
that will be described subsequently, and Is not in 
any sense meant to be exhaustive. 

The parameters that can be specified for a 
query request include the following: 

Input Search Argument (typically, the name of the 
object) Directory Type ID 

Information Desired 

Whether the query Is to t>e local only. 

There are two basic ways the query mecha- 
nisms can be described: directed and undirected. 



THE DIRECTED QUERY MECHANISM 

This is the simplest query mechanism, and in it 
the user specifies the identity of the DSU to which 
the query message muste be sent-the target DSU, 
The DSU to which the user is attached (the source 
DSU) would then use the transport mechanism to 
send a message to the target DSU. The target DSU 
would receive this message, perform the necessary 
operations on its local directory and respond as 
appropriate. The target DSU would not propagate 
the message to any further remote DSU. 

Figure 16 depicts an example of the use of a 
directed query. It wille be noted that the use of a 
directed query does not Imply physical adjacency 
of source DSU and target DSU. The mechanism 
can be used where the user knows the target DSU 
and the underlying transport provides a commu- 



nication path to the target DSU. The mechanism 
cannot be used if either of the above conditions are 
not satisfied. While the secorKl condition may be 
satisfied in many environments, it is probably un- 
s likely that the user will know the identity of the 
target DSU. Special' cases where the user has this 
Infonnation may include: 

1. The user obtains this information through 
some mechanism defined by the user. An example 

10 of this mode of operation is If the name of the 
object contains the identity of the target DSU. 

2. A directory service can nr\aintain a speda! 
directory which contains the Identities of the target 
DSUs for certain objects in the network. The user 

75 would query this special directory, obtain the target 
DSU information, and then initiate a directed query. 
This special directory may also be maintained 
through one of the queryAjpdate mechanisms. Fig- 
ure 17 depicts an example of the use of this 

20 special directory. 

If either condition described above does not 
prevail, or if it de^red that target DSUs propagate 
the query further, the directed mechanism cannot 
be employed. 

25 

THE UNDIRECTED QUERY MECHANISM 

In the undirected mechanism, the user does 
30 not provide the identity of the target DSU. Instead, 
the propagation of queries Is guided by data struc- 
tures, know as propagation tables or P-tables. 
Each DSU maintains, for each directory type, a P- 
table which detenmines, for that directory type, 
35 which other DSUs to send query messages to. 

Upon receipt of an undirected query, the 
source DSU consults Its P-table for that directory 
type and, based on the information contained in the 
P-tab!es. sends a. query message to one or more 
40 DSUs. The DSUs that receive the message consult 
their own P-table and may propagate the query 
further. Rgure 18 depicts a typical example of this 
type of query propagation. 

The fact that the receiving DSU may propagate 
45 the message further creates two possible causes of 
incorrect operation. Firstly, there is the possibility 
that the query sent to one DSU, (DSU B in the 
example shown in Fig. 18). is not propagated while 
the query sent to another DSU is propagated (DSU 
so C). resulting in the response from one DSU arriving 
very much before the response from the other. 
Incorrect operation may result if the source DSU 
responds to the user and erases any memory of 
the query immediately after the first response. 

55 
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Secondly, there is the possibility that query 
messages may *ioop', Por example in Rgure 19. 
the P-tabl8S are set up so that DSU A sends 
queries to DSU B. and DSU B send queries to DSU 
C. If no mechanism was in place to prevent loop- 
ing, queries could bounce back and forth between 
the two DSUs forever. 

The mechanism that will be described in the 
following sections solves the above problems by 
creating a special control block for each query and 
maintaining that control block until 'propagation has 
terminated. Further details are discussed tietow 
under "The Basic Query Propagation Mechanism". 



P-Tables 

The P-tables at the various DSUs define how 
the DSUs interact with one another in performing 
queries. Each DSU in the network contains P-tables 
for every directory type for which It may perform 
undirected queries. The Potable in a DSU contains 
the identities of some of the other DSUs in the 
network. It must be possible to establish e commu- 
nication path with any DSU that appears in a P- 
table. 

The P-table consists of two parts, a query P- 
table (QP-table) and an update P-tabie <UP-table). 
Additional description of the function and use of the 
update P-tables is contained in the above-referen- 
ced copending application (A3), Additional descripn 
tion of the directory control block and the query 
control -block used in query propagatton is con- 
tained in the above-referenced copending applica- 
tion (A2). The QP-table defines the DSUs to which 
queries are sent. The structure of the tables is 
shdwn in Figure 20. In addition to containing the 
identities of ttve DSUs these tables define the order 
in which the DSUs are queried, by specifying a 
numeric parameter or priority associated with each 
DSU. The DSU with the highest priority is sent the 
query message first while DSUs w'rth equal priority 
receive the messages in parallel. As Figure 20 also 
dec«cts. there is an extra algorithm control field 
associated with each DSU entry. 

The following describes the processing of que- 
ries and updates, with or without propagation. The 
different cases involved in such processing include: 

Query Processing at the origin DSU without 
propagation -the origin DSU receiving the query 
request from the user satisfies the request from the 
locally residing directory without propagation. 

Query Processing at the origin DSU with prop- 
agation. The origin DSU cannot locally satisfy the 
request from the user and, therefore, originates the 
query request for propagation to other remote 
DSUs. 



Query Processing at the intermediate DSU - 
The intermediate DSU receiving a query request 
from the remote DSU cannot satisfy the request 
and, therefore, propagates the query request fur- 

5 ther to other DSUs. 

Query Processing at the target DSU -The tar- 
get DSU receiving a query request retrieves the 
requested data and send the query reply toward 
the origin DSU. 

10 Update Processing at the origin DSU -The ori- 

gin DSU receiving an update request from the user 
originates the update request for the propagation to 
the DSUs to be affected. 

Update Processing at the intermediate DSU - 

15 The intermediate DSU receiving an update request 
from the remote DSU propagates the update re- 
quest further to other DSUs to be affected. 

Each case will be descrit>ed separately by con- 
sidering only those compor>ents of the directory 

20 system structure that are required to process the 
given case. In the drawings, solid lines with arrows 
denote procedure CAU-S. Dotted lines with arrows 
denote the execution of the protocol tx^undaries or 
the access of the control data block. Rgure 14 

25 illustrates the directory system model for the query 
processing, while Rgure 13 illustrates the directory 
system model for update processing. 



Query Processing at Origin DSU (No propagation) 

The processing steps include: 
35 1. The application program calls the API_^ 

Query Send Processor to pass the QUERY verb. 

2. The AP! Query Send validates its 

syntax and parameters. The API^ Query Send 

calls the DSI Query RQ processor to pass the 

40 Query request tor processing. 

3. The DSI Query RQ processor calls 

the Data^ Read processor to request the data. The 
Data__Read processor retrieves the requested di- 
rectory data by managing the data access protocol 

45 t>oundary according to the directory descriptors, 
and returns the retrieved data to the 
DSI_Query_RQ. 

4. TTie DSI_Query RQ constructs the DSI 

query reply which carries the retrieved data, and 

so calls the DS!_Query_Reply processor to pass the 
query reply. 

5. The DSI__Query_Reply processor man- 
ages the finite state machines associated with the 
query request and calls the API Query^Reply 

55 processor to present the results of the query to the 
application program. 
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6. The API_Query__Reply Processor de- 
codes the DSI query reply and places the resulting 
data into the queue. 

Control is eventually returned to the 

API Query Send. At this time, the 

API Query_Send returns control wHh the return 

code ("successful") to the application program. 



application program. Optionally, the results of the 
query can be retained in the local directory by 
calling ttie Data_Write processor, 

10. The API_Query__Reply Processor de- 
codes the DSI query reply and places the results of 
the query into the queue. Optionally, application 
program is scheduled for each enqueued query 
result 



Query Processing at the origin DSU (Propagation) 

The processing for the case where the origin 
DSU cannot satisfy the query request from the 
local directory, thus originating the DSI query re- 
quest for propagation to other remote DSUs, is as 
lollows: 

1. The application program calls the 
APl_Query__Send Processor to pass the QUERY 
verb. 

2. The API Query^Send vafidates its syn- 
tax and paramemeters ters. The 
APl_Query_Send calls the DSI__Query_RQ pro- 
cessor to pass the Query request for processing. 

3. The DSI_Quary_RQ processor calls the 
Data__Read processor to request the data. The 
Data Read processor returns an indication that ft 
cannot find the requested data from the local direc- 
tory. 

4. The DSl_Query_RQ calls the Query Al- 
gorithm which is one of the Directory alogorithm 
facilities. The query algorithm determines which 
DSU to send the DSI query request to for remote 
search. 

5. The DSI_Query RQ places the destina- 
tion DSU name (which indicates the next DSU for 
the request to be delivered to) in the appropriate 
*field of the DSI query request, and calls the 
Data__Send processor to send the DSI query re- 
quest through the network. 

6. The Data__Send processor manages the 
network protocol boundary for proper delivery of 
the DSI query request to the destination DSU. At 
this time control will be returned to the 
API_,Query_Send through the DSl_Query_RQ, 
and API_Qu©ry_Send returns control with the re- 
turn code ("successful") to the application pro- 
gram. 

7. The Data_Receive processor receives 
the DSI query reply carrying the requested data 
from the remote DSU through the network protocol 
boundary. 

8. The Data Receive processor calls the 

OSI_Query_Rep!y processor to pass the DSI 
query reply received from the remote DSU. 

9. The DSI Query^Reply processor man- 
ages the finite state machines associated with the 
query request, and calls the APl__Query_Reply 
processor to present the results of the query to the 



70 

Query Processing at an Intemiediate DSU 

The processing for the case where the inter- 
mediate DSU receives a DSI query request but it 
75 cannot service the query request from the local 
directory* thus sending the DSl query request for 
propagation to other remote DSUs, is as follows: 
Processing steps: 

1. The Data Receive processor receh/es 

20 the DSI query request from the remote DSU 
through the network protocol tx5undary. 

2- The Data_Receive processor calls the 
DSI Query RQ processor to pass the DSI query 
request received from the remote DSU. 
25 3. The DSI__Query_RQ processor calls the 

Data Read processor to request for the data. The 
Data^Read processor returns an* indication thai It 
cannot find me requested data from the local direc- 
tory. 

30 4. The DSl_Query_RQ calls the Query Al- 

gorithm to determine which is the next DSU for 
query propagation. 

5, The DSl__Query RQ places the destina- 
tion DSU name in the appropriate field of the DSI 

35 query request, and calls the Data^Send processor 
to send the DSI query request through the network- 

6. The Data_Send processor manages the 
network protocol boundary for proper delivery of 
the DSI query request to the desfinaljon DSU. 

40 

Query Processir>g at Target DSU 

The processing for the case vrtiere the target 
4S DSU receives a DSI query request from a remote 
DSU. retrieves the requested data from the local 
directory and sends the DSI query reply toward the 
origin DSU is as follows: 
Processing steps: 
so 1. The Data_Recehre processor receives 

the DSI query request from the remote DSU 
through the network protocol tKjundary. 

2. The Data^Receive processor calls the 
DSl_Query RQ processor to pass the DSI query 

55 request received from remote DSU. 

3. The DSl_Query_RQ processor calls the 

Data Read processor to request for the data. The 

Data^Read processor retrieves the requested di- 
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rectory data by managing the data access protocol 
boundary according to the directory descriptors, 
and returns the retrieved data to the 
DSi_Quory__RQ, 

4. The DSl_^Query_RQ constructs the DSI 
query reply which carries the retrieved data, and 

cans the Data Send processor to send the DSI 

query request through the network. 

5. The Data_Send processor manages the 
network protocol boundary for proper delivery of 
the DSI query request to the destination DSU. 



Creation of P-Tables 

The entries in each P-table may be created in 
severai different ways. They may be linked directly 
to the way in which data is distributed through the 
system, something whk:h may be specified in the 
form of an affinity table. 

Alternatively, the P-tables may be defined di- 
rectly at system generation time and remain un- 
changed through the entire directory operation tion, 
or may be updated dynamically. They may also t^e 
created during operation or through other mecha- 
nisms such as queries to a 'directory of directories* 
or through input from the network routing function. 



Access of P-Tables 

Furthermore, the protocol tx)urKJary may permit 
only indirect access to the P-tables. The indirection 
is in that the user does not specify the actual 
entries in the P-tables, but. instead, specifies the 
way in which he wants data distributed through the 
network using cert^n data distribution primitives. 
These notions are then translated automatically into 
entries in P*tables. 

The advantage of this indirect approach is that 
it enables the user to think of the directory struc- 
ture only in terms of data distributton, something 
that is intuitive and easy to understand, while 
shielding him from the complexities of understan- 
ting me ftow of queries. The disadvantage of this 
approach is that it limits flexibility arwl prevents the 
user from exercising the full range of query propa- 
gation options that is possible if direct access to 
the P-tables is pemnitted. 



DATA DISTRIBUTION PRIMITIVES 

The user may define some data distribution 
reiattonships between the DSUs in the network. 

6 This section describes the relationships, how they 
are used to set up a directory service system, and 
how these relationships then gat translated into P- 
table entries. 

In understantirig the motiviation behind the 

70 translation, it is important to understand the 
"duality" between queries. In particular, if DSU A 
always sends an ujxtate to DSU B whenever it 
changes its directory, there is no necessity for DSU 
B to ever query DSU A. Conversely, if DSU B 

76 always queries DSU- A. there is no necessity for 
DSU A ever to send updates to DSU B. The 
translation frwn data distribution to P-table entries 
is designed to take this "duality** into account and 
thus to conserve on the use of communication 

so bandwidth. 

The relationships are with respect to a specific 
directory type ID. It is possible ar>d indeed likely 
that the relationship for different directory type ID*s 
will be quite different. The following data distribu- 

25 tion relationships can tke defirted: 



Sup-Sub Relationship 

30 The superior (SUP)-subordinate (SUB) relatior>- 

ship is depicted piclorially in Fig. 21 by a directed 
arc from A to B. A is the SUB and B is the SUP. 
The relationship is established by specifying at A 
that B is a SUP of A and by specifying at B that A 

35 is a SUB of B. This relationship implies that under 
-normal** conditions a communication path exists 
from the SUB to the SUP through the transport 
mechanism. In terms of data distribution, it implies 
that if X is the directory type ID for which this 

40 relationship has been -defined, then B's directory of 
type ID X is a superset of A's directory of the same 
type ID. 

The translation into P-table entries attempts to 
preserve the nature of the relationship. As B is the 
45 SUP of A, both queries are propagated from A to 
B. However, as B's directory contains all the in- 
formation that A*s directory contains, B neither que- 
ries rK>r up>date5 A. The translation to P-table en- 
tries in A and B is depicted in Figure 22. 



Peer-Peer Relationship 

As shown in Rg. 23, this relationship is de- 
picted pictorially by an undirected arc between the 
PEERS. The relationship is established by specify- 
ing at A that B is a PEER of A and by specifying at 
B that A is a PEER of B. This relationship implies 
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that the PEERs can communicate with each other 
through the transport mechanism and that the user 
would like them to communicate directiy in order to 
perform directory functions. It does not imply any 
relationship in terms of data distribution. Thus, in 
the translation to P-table entries, queries are ex- 
changed between PEERs, as represented in Fig. 
24. 



Replicated Relationship 

This relationship is depicted pictorially in Fig. 
25 by a bidirectional arc between the DSUs. The 
relationship Is set-up by specifying at A that B is a 
REPLICATE of A and by specifying at B that A is a 
REPLICATE of B. This relationship implies that the 
DSUs can communicate with each other through 
the transport mechanism. In terms of data distribu- 
tion, it is equivalent to two SUP-SUB relationships; 
that is, B is a superset of A and A is a superset of 
B. Clearly, this can be satisfied only if A and B are 
Identical. The translation to Potable entries is de- 
signed to preserve the replication by propagation 
updates between the DSUs as represented in Rg 
26. It will be apparent that many other types of 
relationships are possible. 



Other Relationships 

The examples shown in Figs. 27-30 lllusti'ate 
that the definition of relationships between the 
DSUs in a network determines the data distribution. 
It will be noted that the relationships define a 
network over which queries are normally propa- 
gated. This network is usually a sub-network of the 
network formed by defining all possible commu- 
nication paths. In other words, there may be com- 
munication paths available between DSUs which 
are not normally used in query propagation. 



PRIORITIES OF THE ENTRIES 

It has been shown how the data distribution 
primitives defined get mapped into entries in the 
QP-table and the UP-table. It needs to be shown 
how the priority of these entries is established. 
Consider the UP-table. Clearly, it is advantageous 
\o propagate in parallel to all SUP DSUs, as this 
would enable the update to reach the appropriate 
destinations as soon as possible. Thus, in the 
translation to P-table entries, all entries are given 
equal weight as shown as an example in Fig. 31. 
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Considering the QP-table, both SUPs and 
PEERs are entered into the table. In propagating 
queries. It is not the case that parallel propagation 
is always desirable. In some instances, sequential 

5 propagation may be preferable as it may result in 
less band with being used in query propagation. 
Thus, two basic methods, the parallel and the se- 
quential, are provided for in constructing P-tables. 
The choice of parallel or sequential can be con- 

70 trolled at the time of system definition. 

The parallel approach Is very similar to that 
used in tfie construction of the UP-tables. All SUP 
entries are given equal priority and all PEER en- 
tries are given equal priority. The priority of the 

75 SUPs, however, is higher than the priority of the 
PEERS (that is, a smaller numerical value). For 
reasons that wilt become apparent when the al- 
gorithms are described, the SUPs are assigned a 
negative number as priority. Fig. 32 shows an 

20 example of this. 

This sequential propagation approach assigns 
priority number to the DSUs in ascending order, 
with the SUPs having the smaller numbers, (again 
chosen to be negative), and the PEER'S the larger 

25 number (positive). Fig. 33 depicts this through an 
example. 

The determination of whether parallel or se- 
quential propagation is used is usually made at 
create-configuration time or automatically by 

30 means of a predefined user algorithm, tt is impor- 
tant that all the DSUs that participate in a given 
query use the same mode of propagation. Thus, tt 
is not permitted for the originating node to propa- 
gate a query in a sequential fashion and for inters 

35 mediary nodes to relay that query in parallel fash- 
Ion. In order to ensure this, the query messages 
that are propagated In the network contain a bit 
which indicates whether the DSU that initiated the 
query used sequential or parallel propagation. 

40 Intermediary rrades use the method of propa- 

gation indicated in the query message, thereby 
ignoring the priorities in the QP-table, and creating 
a new set of priorities if the query message speci- 
fies a different mod© of propagation than the mode 

45 for which their QP-tables are set up. 



RELATIONSHIP RULES 

50 The relationships of the DSUs in the networt< 

for a given directory type ID should satisfy certain 
rules. These rules are important in order to main- 
tain internal consistency of the P-table in a given 
DSU, as well as in the relationship between P- 

55 tables in different DSUs. The rules are as follows: 
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2. There exists a OSU .C so that there are 
paths consisting entirely of directed arcs, traversed 
in the indicated direction, from both A and B to C. 
Note that a degenerate case where this condition 
would be satisfied would be if there was a directed 
path from A to B or vice versa. 

In order for the propagation algorithms not to 
use an unecessarily large amount of bandwidth, 
onty one of 1 and 2 above must hold. 

If 8 is PEER<A). then D cannot be SUP(A) or 
REPLICATE(A). Simtlary, if B is SUP(A>. then B 
cannot be PEER(A) or REPLICATE(A); and 

PEER relationships are always reciprocal. Simi- 
larly, if B is SUP(A) then B cannot be PEER(A) or 
REPLICATE{A) and if B = REPLICATE (A) then it 
cannot be PEER(B) or SUP(A). 



THE BASIC QUERY PROPAGATION MECHANISf^ 

This is shown in block diagram form in Fig. 14. 
The query message sent between the DSUs con- 
tains all the informaUon that initiated the query, ertd 
in addition, the identification of the DSU tfiat origi- 
nated the propagation of the query (the source 
DSU), and a con-elation number which ts generated 
by the source DSU, Fig. 34 shows a typical query 
message. Any response message contains the in- 
formation generated in response to the query and. 
importantly, also includes the identification of the 
DSU that was the source of the^ query and the 
correlation number contained in the query. Fig. 35 
shows a typical query response message. 

The combination of source DSU identification 
and correlation number is used by the various 
DSUs in the network to uniquely identify that query 
and to correlate responses to the query with the 
query itself. The DSU identities are required to be 
unique. In order for the combined DSU identity 
plus correlation number to be unique. It is neces- 
sary for the source DSU to ensure that it uses a 
correlation number only If it is certain that no 
instance of any previous query message that it 
may have generated with the same correlation 
number remains in the network. 

A practical method of achieving this is to use 
as a correlation number a time-stamp or a con- 
stantly incremented sequence number, taking care 
to ensure that the size of the correlation number 
fiield and therefore, the time between wrapping of 
the number, is large. The propagation of query 
messages is guided by the P-tables tor that direc- 
tory type at each DSU. 



SUMMARY 

It has beeen successfully demonstrated that 
queries can be propagated across any network 

5 environment or topology. Either theses queries can 
be directed to a target or undirected (automatic) by 
means of the use of P-tables. 

P-tables define relationships (SUP-SUB. PEER- 
PEER, etc.) tjetween directory units (DSUs), wheth- 

70 er they are local or remote. Based on priority and 
the type of propagation desired (sequential or par- 
allel), queries are sent to participating DSUs. In 
addition, tt>e mechanisms also provkle for the user 
to specify his own aigohthms to either propagate 

75 queries or determine the mode. The mechanisms 
thus described provide for Ixjth uru-and bi-direc- 
tional query propagation. Inherent in these mecha- 
nisms is the performance criteria to reduce looping 
and audit trails for recovery. 

Claims 

1. In a directory database system including a 
25 network having a plurality of communication paths 

and a plurality of directory service units (DSU), 
each of said DSUs providing one or more directory 
sen/ice functions within said directory datat>ase, an 
apparatus for propagating a user query relative to 
30 an object from a source DSU to a target DSU 
comprising : 

a special directory containing the identities of tar- 
get DSU's for certain of said objects in said net- 
35 work, 

mear^ for communicating said user query from 
said source DSU to said special directory means 
for generating information identifying the target 
40 DSU for said object embodied in said query, and 

means for communicating said Information relative 
to said identiried target DSU to said source DSU. 

2. In a directory database system ir^cluding a 
45 network having a plurality of communication paths 

and a plurality of direaory service units (DSU), 
each of said DSUs providing one or more directory 
service functions within said directory datat>ase. an 
apparatus for propagation of an undirected user 
50 query relative to an object from a source DSU to 
one or more target DSUs, which target DSU may 
contain information relative to said object, compris- 
ing : 

55 - a propagation (P) table in each of said DSUs, 
each of said P tables being a data structure ca- 
pable of determining which other DSU's to send 
said user query to. 
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-means in said source DSU for examining its asso- 
ciated P table for the directory type specified in 
said query to generate an identification of one or 
more, additional target ones of said DSUs to which 
said query should be directed, 

-means for propagating a query from said source 
DSU to those additional DSU's identified by said P 
table In said source DSU, and 

-means for returning to said source DSU informa- 
tion responsive to said user query from the one of 
said additional target DSU's containing said in- 
formation. 

3. Apparatus in accordance with Claim 2 in- 
cluding means in each of said additional DSU's for 
examining its P table to determine the identity of 
the target DSU to which said query should be 
directed. 

4. Apparatus in accordance with Claim 2 in 
which each of said P tables includes a query P- 
table <QP-table) and an update P-table (UP-table). 

5. Apparatus in accordance with Claim 4 in 
which said QP table defines the one or more target 
DSUs to which a query should be sent. 

6. Apparatus in accordance with Claim 5 in 
which each of said QP tables contain information 
determining the order in which any additional target 
DSUs are to be queried. 

7. Apparatus in accordance with Claim 4 in 
which each of said QP tables in each particular one 
of said DSUs defines the status relationship of said 
particular DSU to other DSUs of the same directory 
type. 

8. Apparatus in accordance with Claim 7 in 
which the QP table in said particular DSU defines a 
superior-sutxjrdinate relationship between said par- 
ticular DSU and one or more of said other DSUs. 



9. Apparatus in accordance with Claim 7 in 
which the QP table in said particular DSU defines a 
peer-peer relationship between said particular OSU 
and one or more of said other DSUs. 
5 10. Apparatus in accordance with Claim 7 in 

which the QP table In said particular DSU defines a 
replicated relationship between said particular DSU 
and one or more of said other DSU's. 

11. Apparatus in accordance with Claim 5 in 
10 which each of said QP tables determines whether 

further propagation of a query to a plurality of other 
DSU's is to be in a serial or a parallel mode. 

12. Directory service system having a plurality 
of interconnectable directory service units (DSU). 

75 characterized in that it comprises a plurality of 
processes within said directory service system, 
said plurality of processes including: 

-a P(U) process for interfacing ym\h a user of said 
20 system at a user protocol boundary; 

-a P(D) process for Interacting with a directory 
database at a directory data access protocol 
boundary; 

25 

-a P{N) process for interacting with a communica- 
tion network at a network control boundary; and 

-a P(F) process for Interacting with at least one of 
. 30 the other of said processes In said directory ser- 
y\ce system. 

13. Directory service system in accordance 
with Claim 12 in which each of said processes is 
tocated in one of said DSUs. 

35 14.Directory service system In accordance wltti 

Clarm 13 in which said directory database with 
which said P(D) process interacts is accessible by 
said P(D) process from the one of said DSUs in 
which said P(D) process is located. 
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